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The  Scenario  Development  Tool:  Enabling  Planners  to  Develop  and 
Refine  a  Plan  at  a  Rapid  Pace 


Abstract 

Military  planners  are  frequently  tasked  with  developing  a  complicated  plan  in  a  short  amount  of 
time  while  employing  minimal  resources.  Current  planning  processes  are  conducted  manually 
and  planner  must  collaborate  through  face-to-face  or  digital  communications.  We  propose  a 
software  planning  tool  that  will  use  an  existing  simulation  to  allow  planners  to  input  a  variety  of 
controllable  and  uncontrollable  variables.  The  Scenario  Development  Tool  (SDT)  will  then 
execute  the  underlying  simulation  and  present  the  user  with  response  surfaces.  While 
limitations  exist,  the  SDT  has  the  potential  to  be  a  valuable  tool  for  all  military  planners.  The 
tool  has  achieved  an  initial  capability  and  is  able  to  run  on  a  limited  scenario.  Initial  results  and 
future  potential  are  discussed. 


Problem  Statement 

Recently,  military  commanders  have  sought  to  train  the  way  they  intend  to  fight.  In 
order  to  accomplish  this  task,  numerous  techniques,  programs,  and  methods  have  been 
adopted  over  the  years  resulting  in  a  myriad  of  various  doctrines,  programs  of  record  and  a 
veritable  alphabet  soup  of  Three-Letter  Acronyms  (TLAs).  The  purpose  of  these  artifacts  is  to 
provide  a  commander  with  a  better  plan  more  quickly;  and  they  are  successful  in  accomplishing 
this  goal.  However,  the  planning  process  is  extremely  time  and  labor  intensive,  leading  to 
greater  expenses  and  higher  levels  of  coordination  required  reaching  a  final  plan.  Among  these 
methods  are  the  Joint  Operational  Planning  Process  (JOPP)  and  Homeland  Security  Exercise  and 
Evaluation  Program  (HSEEP). 

In  fact,  the  state  of  operational  planning  has  changed  little  in  the  last  hundred  and  fifty 
years.  In  1857,  General  Helmuth  von  Moltke  (German  Army)  instituted  a  planning  process 
similar  to  what  we  still  use  today,  with  an  emphasis  on  commander's  intent  and  allowing 
subordinate  commanders  a  degree  of  flexibility  to  act  within  a  senior  commander's  guidelines 
[1].  The  JOPP,  as  described  in  the  Joint  Publication  5-0  [2],  remains  remarkably  similar  to  the 
steps  described  by  von  Moltke.  Current  operational  and  exercise  planning  processes  consist  of  a 
finite  number  of  steps,  none  of  which  are  currently  automated.  In  addition,  the  steps  differ 
slightly  in  the  Navy  Planning  Process  and  Marine  Corps  Planning  Process,  but  remain  essentially 
the  same.  The  process  can  be  summarized  as  follows: 

A  Combatant  Commander  (or  other  senior  officer)  offers  guidance  and  a  mission 
statement  at  the  strategic  level.  This  is  the  Commander's  Intent.  A  Commander  then  gathers 
large  groups  of  specialists  from  among  his  or  her  own  staff  and  subordinate  units  to  receive 
guidance  and  begin  planning.  These  specialists  will  organize  by  staff  sections  (J3  =  Operations; 
J4  =  Logistics;  etc.)  or  along  operational  functions  (C2,  intelligence,  fires,  movement  and 
maneuver,  force  protection,  and  sustainment).  These  specialists  work  in  their  respective 
domains  while  at  the  same  time  coordinating  across  domains  to  conduct  a  thorough  mission 
analysis,  develop  possible  courses  of  action  (COAs),  analyze,  compare  and  ultimately 
recommend  one  of  the  COAs  to  the  Commander.  Once  the  plan  has  been  approved,  a  detailed 
order  will  be  generated  with  specific  instructions  for  each  aspect  of  the  mission. 

The  JOPP  is  completely  manual  in  its  mechanisms  (see  Figure  1).  The  entire  JOPP  can  be 
executed  without  the  use  of  a  single  computer.  Possibly,  the  most  computationally  intensive 
process  required  is  a  Microsoft  PowerPoint  presentation  for  the  Commander  to  receive  the 
COA  briefs.  The  JOPP  also  requires  gathering  many  people  from  many  different  organizations 
(often  with  differing  and  competing  interests)  for  a  long  period  of  time.  In  the  fiscally 
constrained  environment  in  which  we  live  and  operate,  this  process  translates  to  elevated 
travel  budgets,  more  time  away  from  other  duties  and  overall  inefficiency. 
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Figure  1:  Joint  Operation  Planning  [6] 

Despite  the  obvious  complications  and  difficulties  the  JOPP  presents,  it  has  remained 
essentially  the  same  for  generations.  The  reason  this  process  has  not  yet  been  automated  is 
current  models  do  not  support  a  key  aspect  of  the  entire  planning  process  which  is  the  notion 
of  iterative  dialogue.  The  dialogue  needs  to  be  conducted  face  to  face  between  subject  matter 
experts  (SMEs)  throughout  stages  one  through  five  of  the  JOPP.  If  it  does  not  occur,  each 
section  will  be  planning  in  a  vacuum  and  could  possibly  move  forward  on  faulty  assumptions. 

An  example  helps  elucidate  the  JOPP  shortcomings.  Consider  an  amphibious  force 
planning  an  opposed  landing  on  a  hostile  beach.  This  planning  team  will  consist  of  Navy  and 
Marine  Corps  planners  from  a  variety  of  backgrounds.  There  will  be  experts  from  the  Surface 
Navy,  Aviation,  Mine  Warfare,  Logistics,  C2,  etc,  as  well  as  Marine  Corps  SMEs  for  Aviation,  C2, 
Logistics,  Ground  Maneuver  Elements,  and  Intelligence  all  planning  together  to  determine  a 
proposed  scheme  of  maneuver  for  all  units  involved  in  the  execution  of  the  amphibious  landing. 
This  group  will  determine  a  workable  plan  based  on  input  from  each  SME.  However,  if  one 
party  is  not  available  or  unable  to  share  information,  then  the  plan  could  completely  fall  apart. 


Within  our  example,  the  fires  section  who  is  responsible  for  delivering  ordnance  to 
targets  plans  on  employing  100  bombs  per  day  to  achieve  their  desired  results.  However,  if  the 
supply  section  can  only  provide  80  bombs  per  day,  then  the  Commander  Landing  Force  (CLF) 
will  need  to  change  his  scheme  of  maneuver  and  slow  his  advance  based  on  the  slower  rate  of 
ordnance  delivery  causing  the  entire  plan  to  be  reassessed.  The  example  highlights  the  fact  that 
all  planners  must  maintain  situational  awareness  of  what  planning  factors  present  limits  for 
each  staff  section. 

In  today's  fiscally  constrained  environment,  commanders  are  more  likely  to  use 
computer-aided  exercises  (CAX)  than  live  exercises  to  rehearse  existing  operational  plans 
(OPLANS)  and  to  conduct  battle  experiments  in  order  to  determine  more  effective  and  efficient 
avenues  to  carry  out  their  missions.  The  future  of  military  training  including  military  planning  is 
in  the  digital  field  [3].  The  future  JOPP  must  provide  military  planners  and  trainers  with  the 
ability  to  train  in  an  effective  way  so  that  they  are  ready  to  face  the  challenges  of  the  future. 
The  elements  must  be  broken  down  and  approached  so  that  software  can  capture  key 
elements  of  the  planning  process  and  present  them  to  a  user  in  a  familiar  fashion. 

In  this  paper,  we  propose  an  approach  to  enable  exercise  and  operational  planners  to 
rapidly  develop  and  assess  scenarios  that  will  serve  the  warfighter  and  training  audiences 
equally  well.  This  Scenario  Development  Tool  (SDT)  serves  as  a  domain-specific  interface  to 
existing  military  simulations.  It  offers  the  warfighter  and  training  audiences:  (1)  a  familiar 
means  to  specify  planning  constraints  (discrete  and  continuous)  and  (2)  the  ability  to  visualize 
the  effects  of  applying  the  specified  constraints  to  the  simulation  via  response  surface.  More 
specifically,  this  tool  will  use  an  interface  to  define  plans  and  orders  that  will  be  sent  to 
modeling  and  simulation  (M&S)  systems  for  execution. 

Specifying  Planning  Constraints 

There  are  two  classes  of  planning  constraints  that  can  be  specified  in  the  SDT: 
controllable  factors  and  uncontrollable  factors.  Controllable  factors  describe  variables  over 
which  a  commander  has  some  degree  of  control  (e.g.,  force  composition,  readiness,  logistics). 
Uncontrollable  factors  consist  of  environmental  conditions  (sensors,  terrain,  weather), 
adversary  forces  (composition,  location,  readiness,  willingness),  and  neutral  /  local  population 
(pro  U.S.,  anti-U.S.,  neutral). 

An  integral  part  of  this  tool  is  the  customized  interface.  The  user  (an  operational 
planner  or  a  trainer)  will  be  able  to  customize  all  inputs  in  an  intuitive  fashion.  All  input 
variables  (both  discrete  and  continuous)  will  be  represented  in  a  simple,  user-friendly,  manner, 
allowing  for  any  user  to  be  able  to  use  the  SDT  from  the  day  of  delivery  [4].  A  simple,  intuitive 
interface  allows  for  dramatically  shorter  periods  in  which  the  user  must  be  trained  on  the  SDT. 
Most  planners  are  familiar  with  Microsoft  Windows  and  Office  products;  therefore,  it  is 
preferable  to  borrow  from  the  functionality  in  those  product  lines  rather  than  creating  a  new 
interface  from  scratch.  By  using  a  layout  similar  to  Figure  2  and  then  allowing  the  user  to 
choose  via  radio  buttons  and  sliders  the  specific  variables  they  wish  to  examine,  the  training 
time  for  a  new  user  of  the  SDT  will  be  drastically  reduced. 
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Figure  2:  Sample  Folder  Structure 

Planners  currently  use  a  variety  of  software  programs  when  conducting  detailed 
planning.  They  frequently  use  Microsoft  Office  products,  such  as  Excel,  Word,  and  PowerPoint 
to  create  a  central  database  for  data.  As  plans  change  and  adapt,  however,  version  control 
becomes  a  serious  issue,  with  one  group  working  on  old  assumptions  while  other  groups  have 
moved  on  to  the  next  issue.  The  SDT  interface  should  include  access  to  and  storage  for  these 
files  and  allow  multiple  users  to  access  them  and  make  changes  while  keeping  track  of  current 
and  previous  versions.  Another  collaborative  tool  must  also  be  included.  A  chat  server  allows 
users  from  any  location  to  interact  and  share  information  in  real  time.  Defense  Connect  Online 
is  an  existing  program  that  allows  users  to  connect  via  video,  audio,  and/or  text.  The  SDT 
should  leverage  this  program  to  allow  users  to  collaborate  in  real  time.  Without  this  capability, 
all  planners  must  be  co-located  so  that  they  can  share  the  required  information  to  make  the 
plan. 


Once  the  constraints  are  specified  and  a  plan  is  formulated,  we  can  use  the  following 
simulations  to  execute  it: 

•  One  Semi  Automated  Forces  (OneSAF):  OneSAF  supports  military  combat 
training,  experimentation,  and  weapon  systems  acquisition  from  the  troop-level 
to  the  command  level.  It  features  the  replication  of  solider  fatigue,  terrain 
obstacles  (i.e.  trees),  and  limited  line  of  sight  due  to  weather  conditions.  While 
OneSAF  is  not  an  analytical  combat  model  by  design  it  is  HLA  and  DIS  compliant 
and  enables  weapon  systems  to  be  parameterized  with  data  generated  from 
line-level  engineering  models. 

•  Combined  Arms  Analysis  Tool  for  the  XXIst  Century  (Combat  XXI):  Combat  XXI  is  a 
flexible,  high  resolution,  accredited,  analytical  combat  model.  It  can  be  used  in 
air  defense,  artillery,  dismounted  infantry  and  combined  arms  studies  to  assess 
the  performance  of  weapon  systems  within  the  context  of  a  simulated 
operational  plan.  In  similar  fashion  to  OneSAF,  Combat  XXI  enables  the 
engineering  of  weapon  systems  to  be  parameterized. 

It  is  possible  to  use  other  simulations  and  in  fact  we  need  a  flexible  architecture  that  would 
allow  us  to  plug  any  simulation  as  needed.  The  SDT  uses  the  coalition  battle  management 


services  (CBMS)  [5]  as  the  link  between  the  interface  and  the  simulations.  We  also  rely  on  the 
Military  Scenario  Definition  Language  (MSDL)  [6]  as  a  standardized  language  to  describe  the 
static  aspects  of  the  plan  (terrain,  force  structure,  weather)  and  the  Coalition  Battle 
Management  Language  (C-BML)  [7]  to  capture  tasks  orders  and  reports  that  flow  between  the 
SDT  and  the  simulation. 

An  extension  to  the  C-BML  schema  has  been  added  to  support  three  new  report  types: 
advertisement,  discovery  and  alert.  An  advertisement  report  lists  the  entity  types  a  CBMS  client 
is  capable  of  creating.  A  client  posts  this  advertisement  when  it  is  initialized  to  inform  other 
subscribing  clients  of  its  supported  entity  types.  This  information  may  be  used  by  subscribing 
clients  for  the  generation  of  an  initialization  file,  such  as  a  MSDL  file.  A  discovery  report  is 
generated  when  an  initialization  file  is  received  by  a  client.  It  lists  the  valid  activity  codes  that 
may  be  assigned  to  each  supported  entity  type  read  from  the  initialization  file.  This  activity 
code  list  may  then  be  used  by  subscribing  clients  to  generate  a  task  file.  An  alert  report  is  a  list 
of  internal  warnings  and  errors  raised  by  a  client,  such  as  a  fire  task  failure  because  an  entity  is 
out  of  range.  This  report  includes  the  alert  message,  severity,  and  the  source  of  the  alert. 

It  is  important  to  note  that  we  can  also  focus  on  specific  aspects  of  planning  by  examining  the 
effects  of  introducing  future  capabilities  into  the  planning  process.  For  instance  we  can  use  the 
framework  for  assessing  cost  and  technology  (FACT)  to  specify  the  design  of  a  future  system, 
introduce  the  future  system  into  a  plan  and  use  a  simulation  to  execute  the  plan  and  compute 
potential  effects.  This  will  give  decision  makers  the  capability  to  objectively  assess  the 
performance  of  potentially  tens  of  thousands  of  system  designs. 

Response  Surface  Visualization 

Recall,  the  goal  of  the  SDT  is  to  enable  planners  to  quickly  develop  and  assess  plans.  The  SDT 
takes  a  novel  approach  to  achieving  this  feature  by  employing  simulations  which  enable 
planners  to  explore  the  effects  of  their  specified  constraints.  The  goal  is  to  provide  a  usable, 
automated  means  for  planners  to  determine  the  sensitivity  of  key  scenario  outcomes  in 
response  to  their  specified  constraints.  The  SDT  realizes  this  through  a  response  surface.  The 
input  variables  visualized  in  the  response  surface  reflect  the  planner's  specified  constraints 
while  the  output  variables  (key  scenario  outcomes)  are  limited  to  what  the  simulation  can  track 
and  are  based  on  what  commanders  and  planners  will  likely  desire  to  assist  in  their  decision 
making.  Examples  of  key  scenario  outcomes  that  can  be  visualized  include:  resources 
remaining  (ammunition,  fuel,  etc.),  attrition  (friendly,  hostile,  and  neutral),  break-through  value 
[8],  and  a  collateral  damage  rating  (See  Figure  3). 
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Figure  3:  Inputs  and  Outputs 


SDT  Limitations 

While  our  approach  and  the  SDT  demonstrate  a  great  leap  forward  in  scenario 
development  and  testing,  it  also  presents  some  serious  limitations.  Since  the  SDT  is  an 
interface  to  an  existing  simulation,  the  visualized  response  surfaces  are  only  as  reliable  as  the 
employed  simulation.  In  order  to  produce  valid  data,  the  simulation  must  be  able  to  process 
and  adapt  to  a  variety  of  variables.  Therefore  employing  simulations  with  adaptive  intelligence 
capabilities,  through  human  interaction  or  artificial  intelligence  is  required.  Failing  to  use  an 
"intelligent"  simulation  will  not  account  for  the  adaptations  that  an  actual  user  will  make  to 
adjust  to  the  current  set  of  variables  and  could  result  in  invalid  response  surface  data.  Another 
simulation-related  limitation  of  the  SDT  is  that  it  currently  does  not  support  stochastic 
simulations.  Within  the  planning  community  it  is  prudent  to  account  for  multiple  possibilities 
when  assessing  a  plan.  The  SDT,  as  currently  conceived,  allows  the  user  to  specify  planning 
constraints,  but  does  not  allow  for  a  stochastic  deviation  from  the  selected  inputs.  This  is 
especially  useful  in  environmental,  opposing  forces,  and  neutral  forces  categories.  Finally,  the 
SDT  must  be  customized  for  each  underlying  simulation  since  different  simulations  reflect  a 
variety  of  different  interoperability  levels  [9].  The  variety  of  simulations  and  interoperability 
increases  the  expense  of  the  tool  by  requiring  programmers  to  customize  the  interface 
between  the  SDT  and  the  underlying  simulation. 

Company  Example 

In  order  to  elucidate  the  capabilities  of  the  SDT,  we  applied  it  to  a  case  study  scenario. 
In  the  case  study  scenario,  a  company  sized  formation  of  tanks  is  charged  with  taking 


possession  of  a  home  (Oscar  1)  that  is  occupied  by  enemy  combatants.  The  company  consists 
of  two  tank  platoons,  one  U.S.  Army  and  the  other  French  Army. 

The  Company  executes  a  series  of  tasks  in  order  to  achieve  the  commander's  desired 
end  state.  That  end  state  is  possession  of  Oscar  1  by  friendly  forces.  The  tasks  executed  by  the 
Company  are: 

1.  Move  to  a  secure  area  and  place  a  device  monitoring  Oscar  1. 

2.  Move  along  a  discrete  path  to  a  location  close  to  Oscar  1  to  settle  in  for  an  assault. 

3.  Assault  and  clean  the  enemies  at  Oscar  1,  seize  possession  of  the  house. 

4.  Fall  North  of  Oscar  1  and  install  a  monitoring  device  to  the  North,  West,  and  East  of 
the  seized  location. 


Assumption  Exploration 


Figure  4:  Sample  Response  Surface 

Suppose  the  Commander  of  the  Company  wanted  to  conduct  battle  experiments  to 
determine  the  minimum  resources  and  training  levels  required  to  achieve  his  goals  while 
keeping  friendly  attrition  levels  at  a  minimum.  Using  the  SDT,  they  could  experiment  with 
varying  readiness  levels  for  friendly  and  enemy  forces  as  well  as  the  initial  level  of  fuel  for 
friendly  forces.  These  input  variables  are  samples  only.  The  commander  could  choose  any 
number  of  resources  to  track  as  long  as  the  underlying  simulation  has  the  ability  to  track  them. 
These  input  variables  would  be  chosen  in  the  SDT  and  a  resulting  response  surface  would  then 
be  presented.  The  simulation(s)  (in  this  case  OneSAF)  executes  the  scenario  for  the  specified 
experimental  conditions.  The  resulting  response  surface  is  shown  in  Figure  4.  It  is  merely  for  the 
purposes  of  this  case  study  and  does  not  represent  actual  data.  Since  the  SDT  hides  the 
simulation  from  users  there  is  no  need  to  spend  computational  time  visualizing  the  execution  of 
the  simulation(s).  The  result  is  nearly  immediate  feedback  to  the  user  creating  a  framework 


where  they  can  efficiently  experiment  a  variety  of  conditions  to  determine  optimum  values  for 
successful  training/planning. 

Conclusion  and  Future  Work 

The  SDT  we  present  here  is  an  initial  step  in  a  much  larger  process  of  meeting  the 
challenge  of  using  computer  simulations  in  support  of  planning.  Ultimately,  the  SDT  has  the 
potential  of  being  the  tool  that  enables  a  more  rapid  development,  review,  and  refinement  of 
plans.  Future  development  of  the  SDT  lies  in  making  it  compatible  with  a  variety  of  simple 
simulations  run  in  various  programs  and  then  using  it  to  develop  more  complicate  and  detailed 
scenarios.  Both  of  these  avenues  of  approach  must  be  followed  concurrently  to  support 
development  of  a  tool  that  will  be  useful  to  all  planners. 

A  key  limitation  of  the  SDT  is  that  it  must  employ  an  existing  simulation.  During  plan 
development  at  the  operational  level,  there  is  rarely  an  existing  simulation  upon  which  to  use 
the  SDT.  Thus,  in  order  for  the  SDT  to  be  effective,  the  planners  must  program  a  simulation  of 
their  always-changing  plan.  However,  use  of  the  SDT  repeatedly  by  each  staff  section  or 
mission  area  can  guide  planners  towards  the  most  efficient  use  of  limited  resources. 
Additionally,  the  future  SDT  will  provide  the  ability  for  planners  to  interact  via  video,  audio  and 
text  chat  allowing  planners  to  conduct  their  "iterative  dialogue."  It  is  easy  to  envision  a  future 
where  planners  will  have  the  ability  to  use  the  Commander's  Intent,  a  list  of  available 
resources,  and  the  SDT  to  rapidly  develop,  review,  and  refine  a  plan.  The  goal  of  the  SDT 
development  team  is  to  make  this  future  a  reality  in  order  to  support  the  warfighters  and  allow 
them  to  use  the  minimum  resources  necessary  to  achieve  success. 
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Scenario  Development  Tool 
Rapid  &  Agile  Planning 
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•  • 


Problem 


□  Planning  is  a  manual,  communication  intensive 
exercise  that  is  expected  to  be  carried  out  in  a 
short  amount  of  time  and  while  employing  minimal 
resources. 


□  Why  aren’t  we  using  existing  simulations  (ONESAF, 
Combat  XXI)? 


Example:  Amphibious  Force  Landing 


□  SMEs  from  Navy  &  Marines  -  Surface,  Aviation, 

Mine  Warfare,  Logistics. 

□  What  is  the  difference  between  Fires  supplying  1  00 
bombs  per  day  vs.  80? 

□  Effect  on  Landing  Force  Rate  of  advance?  Success? 

□  Currently,  everyone  must  know  everything  and  plan 
for  every  scenario! 


Scenario  Development  Tool 

□  Enable  rapid  and  agile  exploration  by  interfacing 
inputs  &  outputs  with  existing  sims. 


□  Web-based,  domain-specific,  graphical  user 
interface  for  input  specification. 


□  Multivariable  output  visualization  via  response 
surfaces. 
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Outputs/Responses 


1  .Feasibility  (0-1  00)  —  Percent  of  friendly  resources  (fuel,  ammunition, 
etc.)  remaining  at  end  of  scenario. 

2.  Break-Through  (BT)  Value  (attack  or  defense).  To  what  extent  is  the 
attacker  able  to  bring  forces  into  the  back  of  the  defender. 

3.  Attrition  (AT)  Value  (attack  or  defense).  To  what  extent  is  the 
attacker  able  to  neutralize  the  defending  forces. 

4.  Operational  Environment  Damage  (OED)  Total  percent  of  non¬ 
friendly  and  non-adversary  entities  (i.e.,  infrastructure,  neutral  forces) 
within  the  boundaries  of  the  scenario  that  remain  usable. 

S.Soundness  —  Can  every  task  be  carried  out  given  the  course 
specified? 


SDT  Workflow 


1.  Scenario  and  value  ranges  of  input  variables  are 
specified  via  graphical  interface. 

2.  A  formal  specification  of  the  scenario  is  built  (i.e.  C- 
BML,  MSDL). 

3.  CBMS  links  the  specification  to  the  computer  simulation 
(ONESAF,  Combat  XXI). 

4. Simulation  is  executed  for  all  specified  value  ranges. 

5. Outputs  of  the  simulation  are  visualized  via  response 
surface. 


Use  Case:  Multi-national  Company 


Use  Case:  Multi-national  Company 


A  Multi-national  Company  plans  to  take  possession  of 
Oscar  1,  a  house  surrounded  by  an  Enemy  force. 

For  mission  success; 

1.  Move  to  a  secure  area  and  place  a  device  monitoring  on 
Oscar  1 . 

2.  Move  along  a  discrete  path  to  a  location  close  to  Oscar  1  to 
settle  in  for  an  assault. 

3.  Assault  and  clean  the  enemies  at  Oscar  1 ,  seize  possession 
of  the  house. 

4  Fall  north  of  Oscar  1  and  install  a  monitoring  device  to  the 
North,  West  and  East  of  the  seized  location. 


Assumptions  to  Explore 


•  Level  of  Fuel 

—  Friendly  Tanks 

•  Readiness  Level 
—  Friendly  Tanks 

—  Enemy  (Oscar  1 )  Equipment 

•  Goal:  See  how  changes  in  resources  and 
readiness  affect  MNC  attrition. 
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Review  of  Exploration 


•  Level  of  Fuel 

—  Friendly  Tanks 

•  Readiness  Level 
—  Friendly  Tanks 

—  Enemy  Equipment 

•  Goal:  See  how  changes  in  resources  and 
readiness  affect  MNC  attrition. 
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Assumption  Exploration 


Multinational  Comp.  Attrition 


What  about  validity? 


□  Exploring  assumptions  gives  us  insight  but  what 
about  validity? 

□  Is  success  -  accomplishing  every  task  -  possible 
given  the  course  specified  in  a  scenario? 

□  If  not,  how  does  failure  occur? 

□  Feedback  should  be  immediate 


□  No  simulation  execution 
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Future  Work 

How  can  we  make  this  more  useful? 

□  Polish  existing  solution 

□  from  development  to  production 

□  Pursue  problems  of  larger  scale. 

□  make  applicable  to  larger  scenarios,  different 
assumptions 

□  Key  Limitation:  A  simulation  related  to  the  scenario 
must  exist. 


